<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
  <link rel="stylesheet" media="screen" type="text/css" href="./style.css" />
  <link rel="stylesheet" media="screen" type="text/css" href="./design.css" />
  <link rel="stylesheet" media="print" type="text/css" href="./print.css" />

  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<div class="dokuwiki export">

<p>
<em>Translations of this page are also available in the following languages:</em> <a href="pcb-projects.ru.html" class="wikilink1" title="pcb-projects.ru.html">Русский</a>
</p>

<h3 class="sectionedit1"><a name="pcb_layout_editor" id="pcb_layout_editor">PCB Layout Editor</a></h3>
<div class="level3">

</div>

<h5><a name="plow_feature" id="plow_feature">Plow feature</a></h5>
<div class="level5">

<p>
A “plow” feature where the line tool shoves existing traces aside
preserving the design rules when possible.
</p>

<p>
<code>Difficulty = 4-5</code>
</p>

</div>

<h5><a name="fast_snap_rounding_algorithm" id="fast_snap_rounding_algorithm">Fast snap rounding Algorithm</a></h5>
<div class="level5">

<p>
Implement a fast snap rounding algorithm and resolve the case where
inserted point cause self-intersection.
</p>

<p>
PCB uses an integer coordinate system for all of its objects. The polygon
clipping code computes all points of intersection between two
non-self-intersecting contours (among many other things it does), but these
points of intersection must also have integer coordinates.
</p>

<p>
A snap-rounding algorithm replaces two segments that intersect at other than
their end points with four segments where each has an end point on an
integer coordinate near the original (non-integer) intersection. Because
this rounding operation on the point of intersection can change the slopes
of the four segments compare to that of the original two, it raises the
possibility that new intersections between the replacement segments and
other segments of the contours occur that did not exist with the original
segments. The snap rounding algorithm needs to produce a collection of
segments where all intersections occur at segment end points having integer
coordinates. The existing code in pcb does this already, but it uses a
theoretically slow algorithm, compared to others that are known, such as:
</p>

<p>
 “Improved output-sensitive snap rounding,” John Hershberger, Proceedings of
the 22nd annual symposium on Computational geometry, 2006, pp 357-366.
 <a href="http://doi.acm.org/10.1145/1137856.1137909" class="urlextern" title="http://doi.acm.org/10.1145/1137856.1137909"  rel="nofollow">http://doi.acm.org/10.1145/1137856.1137909</a>
</p>

<p>
Algorithms described by de Berg, or Goodrich or Halperin, or Hobby would
probably also be better than what we currently have implemented.
</p>

<p>
In addition, there are rare-but-real degenerate situations where the snap
rounding results in one (or both) contours having a self-intersection that
did not exist before. This self-intersection is fatal to our polygon
clipping code. We do not know if the snap rounding algorithms in the
literature deal with this issue or not, but if they do not, we need to
develop a variant algorithm that does, whether done by judicious choice of
the rounding points that are created, or a post-processing step that
eliminates the self-intersection with minimal geometric distortion to the
original contours.
</p>

<p>
<code>Difficulty = 4-5</code>
</p>

</div>

<h5><a name="auto-routed_drawing_tool" id="auto-routed_drawing_tool">Auto-routed drawing tool</a></h5>
<div class="level5">

<p>
Basically with this tool, you would click on a starting point, then drag the
crosshair to some other (typically intermediate point), possibly on another
layer and an auto-routing tool would show a prospective path to that point
(meeting design rules and style requirements). If you didn&#039;t like the
offered path, you could hit a key to see a more expensive candidate, or a
different key to (back up) to a less expensive candidate. The prospective
route would dynamically change to reach the crosshair end-point as the
crosshair is moved. It would disappear if no path could be found. Clicking
would place the prospective path as copper and anchor a new starting point
for the tool (much like the line tool does now).
</p>

<p>
<code>Difficulty = 5</code>
</p>

</div>

<h5><a name="ipc_footprint_calculator" id="ipc_footprint_calculator">IPC Footprint Calculator</a></h5>
<div class="level5">

<p>
Build a footprint calculator that can take the IPC rules and produce a pcb footprint. Preferably write this in a way where the core program is independent of a <acronym title="Graphical User Interface">GUI</acronym> so that you can script it for generating entire large families of footprints or hook it up to a <acronym title="Graphical User Interface">GUI</acronym> of choice (lesstif, gtk, maybe even cgi). Would require the purchase of IPC-7351 (approximately U.S.A. $100) and verifying that one is allowed to produce such a calculator.
</p>

<p>
<code>Difficulty = 2</code>
</p>

</div>

<h5><a name="export_ipc-356" id="export_ipc-356">Export IPC-356</a></h5>
<div class="level5">

<p>
IPC-D-356 is a specification for a netlist output format used for manufacturing test of PCBs.  It specifies both connectivity as well as pad position information, thereby facilitating the use of automated testing after PCB manufacture.  In this project, you would implement an exporter which would write an IPC-D-356 compliant file from within PCB.  The IPC-D-356 <acronym title="specification">spec</acronym> is available at: <a href="http://www.solidigm.com/downloads/ipc356.pdf" class="urlextern" title="http://www.solidigm.com/downloads/ipc356.pdf"  rel="nofollow">http://www.solidigm.com/downloads/ipc356.pdf</a>
</p>

<p>
<code>Difficulty = 3</code>
</p>

</div>

<h5><a name="recently_loaded_file_list" id="recently_loaded_file_list">Recently loaded file list</a></h5>
<div class="level5">

<p>
Presently pcb does not present a list of recently loaded files in the file menu. It would be nice if pcb kept track of the last few files a user loaded. This is a common feature found in other programs.
</p>

<p>
<code>Difficulty = 1</code>
</p>

</div>
<!-- EDIT1 SECTION "PCB Layout Editor" [114-] --></div>
</body>
</html>
